MongoDB must utilize centralized management of the content captured in audit records generated by all components of MongoDB.

Overview

Finding ID	Version	Rule ID	IA Controls	Severity
V-252171	MD4X-00-004800	SV-252171r879729_rule		Medium

Description
Without the ability to centrally manage the content captured in the audit records, identification, troubleshooting, and correlation of suspicious behavior would be difficult and could lead to a delayed or incomplete analysis of an ongoing attack. The content captured in audit records must be managed from a central location (necessitating automation). Centralized management of audit records and logs provides for efficiency in maintenance and management of records, as well as the backup and archiving of those records. MongoDB may write audit records to database tables, to files in the file system, to other kinds of local repository, or directly to a centralized log management system. Whatever the method used, it must be compatible with off-loading the records to the centralized system.

Description

Without the ability to centrally manage the content captured in the audit records, identification, troubleshooting, and correlation of suspicious behavior would be difficult and could lead to a delayed or incomplete analysis of an ongoing attack. The content captured in audit records must be managed from a central location (necessitating automation). Centralized management of audit records and logs provides for efficiency in maintenance and management of records, as well as the backup and archiving of those records. MongoDB may write audit records to database tables, to files in the file system, to other kinds of local repository, or directly to a centralized log management system. Whatever the method used, it must be compatible with off-loading the records to the centralized system.

STIG	Date
MongoDB Enterprise Advanced 4.x Security Technical Implementation Guide	2023-12-18

Details

Check Text ( C-55627r813893_chk )
Administrators can implement collection-level access control through user-defined roles. By creating a role with privileges that are scoped to a specific collection in a particular database, administrators can provision users with roles that grant privileges on a collection level. For example, a user defined role can contain the following privileges: Once enabled, the auditing system can record the following operations: schema changes (DDL), replica set and sharded cluster, authentication and authorization, and CRUD operations (requires auditAuthorizationSuccess set to true). For details on audited actions, see MongoDB documentation on the complete configuration of Audit Event Actions, Details, and Results, and Configuring Audit Filters. To ensure auditing is enabled, confirm the auditLog section in the /etc/mongod.conf configuration file exists and has been set. For example, to enable syslog centralized logging of audit events, in the MongoDB configuration file (by default: /etc/mongod.conf) verify the destination type is set as: auditLog: destination: file format: BSON path: /var/log/mongodb/audit/auditLog.bson -OR- auditLog: destination: syslog If this is not present, is empty, or commented, this is a finding. Review the system documentation for a description of how audit records are off-loaded and how local audit log space is managed. If the DBMS audit records are not written directly to or systematically transferred to a centralized log management system, this is a finding.

Check Text ( C-55627r813893_chk )

Administrators can implement collection-level access control through user-defined roles. By creating a role with privileges that are scoped to a specific collection in a particular database, administrators can provision users with roles that grant privileges on a collection level. For example, a user defined role can contain the following privileges:

Once enabled, the auditing system can record the following operations:

schema changes (DDL),
replica set and sharded cluster,
authentication and authorization, and
CRUD operations (requires auditAuthorizationSuccess set to true).

For details on audited actions, see MongoDB documentation on the complete configuration of Audit Event Actions, Details, and Results, and Configuring Audit Filters.

To ensure auditing is enabled, confirm the auditLog section in the /etc/mongod.conf configuration file exists and has been set.

For example, to enable syslog centralized logging of audit events, in the MongoDB configuration file (by default: /etc/mongod.conf) verify the destination type is set as:

auditLog:
destination: file
format: BSON
path: /var/log/mongodb/audit/auditLog.bson

-OR-

auditLog:
destination: syslog

If this is not present, is empty, or commented, this is a finding.

Review the system documentation for a description of how audit records are off-loaded and how local audit log space is managed.

If the DBMS audit records are not written directly to or systematically transferred to a centralized log management system, this is a finding.

Fix Text (F-55577r813894_fix)
If audit operations filters are not configured in the MongoDB configuration file (default location: /etc/mongod.conf), configure them according to application requirements, but at a minimum, ensure destination and filter are set in a mongod.conf YAML auditLog configuration setting. For example, to audit all database operations involving creating or dropping a collection, the %MongoDB configuration file% (by default /etc/mongod.conf) auditLog section would read as follows: auditLog: destination: file format: BSON path: /var/log/mongodb/audit/auditLog.bson filter: '{ atype: { $in: [ "createCollection", "dropCollection" ] } }' See mongodb documentation for details of audit operations and event configuration. https://docs.mongodb.com/v4.4/core/auditing/ https://docs.mongodb.com/v4.4/tutorial/configure-audit-filters/ Configure and/or deploy software tools to ensure that DBMS audit records are written directly to or systematically transferred to a centralized log management system.

Fix Text (F-55577r813894_fix)

If audit operations filters are not configured in the MongoDB configuration file (default location: /etc/mongod.conf), configure them according to application requirements, but at a minimum, ensure destination and filter are set in a mongod.conf YAML auditLog configuration setting.

For example, to audit all database operations involving creating or dropping a collection, the %MongoDB configuration file% (by default /etc/mongod.conf) auditLog section would read as follows:

auditLog:
destination: file
format: BSON
path: /var/log/mongodb/audit/auditLog.bson
filter: '{ atype: { $in: [ "createCollection", "dropCollection" ] } }'

See mongodb documentation for details of audit operations and event configuration.

https://docs.mongodb.com/v4.4/core/auditing/
https://docs.mongodb.com/v4.4/tutorial/configure-audit-filters/

Configure and/or deploy software tools to ensure that DBMS audit records are written directly to or systematically transferred to a centralized log management system.